Server Flash Cache (SFC) is a technology that enables server systems to use flash storage to accelerate virtual machine (VM) I/O operations. An SFC-enabled server system caches, in a portion of a flash storage device referred to as a “flash cache,” data that its hosted VMs read from and/or write to virtual disks (VMDKs) stored on, e.g., a traditional hard disk-based storage array. When the server system detects a VM read request, the server system services the read request, if possible, from the flash cache rather than from the storage array. Since the I/O latency for flash storage access is typically several orders of magnitude less than the I/O latency for hard disk access, this caching mechanism can significantly improve VM I/O performance.
Generally speaking, each VM or VMDK that a system administrator designates as being part of a server system's SFC configuration is associated with a dedicated portion of flash cache space referred to as the VM/VMDK's “cache allocation.” The size of this cache allocation represents the maximum amount of data the flash storage device can cache for the VM or VMDK; once the cache allocation reaches this cap, the server system must begin deleting cache entries from the cache allocation in order to make room for additional data. An important aspect of managing SFC involves determining the optimal cache allocation size for each VM or VMDK. A VM/VMDK cache allocation size that is too small will decrease the utility of the flash cache for the VM/VMDK because the server system will delete a significant percentage of the VM/VMDK's cache entries before the VM can re-access them. On the other hand, a cache allocation size that is too large will unnecessarily consume space on the flash storage device—space that the server system can better utilize via allocation to one or more other VMs/VMDKs.
In current implementations, system administrators are required to manually define cache allocation sizes for VMs or VMDKs at the time of enabling SFC or at server startup. This manual approach is problematic for several reasons. First, growing CPU bandwidth and memory capacities are allowing for higher and higher VM-to-server consolidation ratios. This makes it increasingly difficult to manually carve out flash cache space on a per VM or VMDK basis, since the number of VMs or VMDKs that system administrators need to consider may be very large. Second, system administrators rely largely on heuristics and guesswork, rather than actual I/O statistics, when defining cache allocation sizes. Thus, more often than not, these manually-defined sizes result in suboptimal cache usage/efficiency. Third, system administrators typically perform cache allocation sizing as a one-time activity—in other words, once the system administrators have defined cache allocation sizes for a server system, the cache allocation sizes remain static throughout the server system's operational lifecycle. As a result, even if the cache allocation sizes work well upon initial configuration, various runtime events (e.g., changing VM workloads, changing storage device service times, events related to VM mobility, etc.) may cause those sizes to become less and less optimal over time.